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UPDATING DIAGNOSTIC DEVICE SOFTWARE AND ENABLING FEATURES 

RELATED APPLICATIONS 
Priority is claimed to U.S. Provisional Patent Application No. 60/392,322, entitled 
'TTse Of XML Protocols For Updating Repair Equipment, Diagnostic Equipment, Tools," 
5 filed on June 27, 2002. The entirety of this Patent AppUcation is expressly incorporated 
herein by reference. 

BACKGROUND 

1. Technical Field 

10 A method and system relating to the field of diagnostic devices, and, more 

particularly, a method for updating software or enabling diagnostic device features for use 
in automotive maintenance and repair, is disclosed. 

2. Description of Related Art 

Recent advances in computer technology have made software-enhanced 
1 5 equipment nearly ubiquitous in developed countries. This apphes especially to equipment 
that, as recently as a decade or two in the past, no one would foresee as using software 
and processors for improved functionality, such as automotive diagnostic equipment. The 
use of relatively inexpensive memory, processors, and displays, for example, has enabled 
manufacturers of such equipm^t to couple legacy diagnostic devices, such as 
20 multimeters, scan tools, lab/ignition scopes, and component testers, with repair and 
diagnostic database software that puts large amounts of repair information literally at 
technicians' fingertips. One such device is the MODIS (Modular Diagnostic Information 
System) produced by Snap-on Technologies, Inc. Because it is modular and software- 
enabled, the MODIS can be updated easily to prevent obsolescence. 
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Even though automotive diagnostic devices have entered tiie realm of high 
technology, they are still highly specialized tools, rather than general— purpose computers. 
Because of this, such devices tend to be stand-alone rather than network-connected 
(although the MODIS, for example, has ample interfaces for communication with 
5 computers and other devices). In addition, they are not generally equipped with Intemet 
access, although they could be. Verifying a user's authorization to access new or updated 
software or installed features is an important function that allows value-enhancing 
updates, but transmitting, receiving, and verifying software keys to verify authorization 
can be somewhat difficult to implement with stand-alone devices. Accordingly, a method 
10 to *\inlock" available but disabled equipment features can allow an equipment 
manufacturer to confidently make software updates, features, and products readily 
available (for example, over the Intemet and on CD-ROMs) without fear of unauthorized 
use. 

SUMMARY 

In one aspect, a method of unlocking at least one feature of a diagnostic device is 
provided. The method may include receiving, from a user, product-identifying 
information (such as a serial number) for the diagnostic device, and identifying a software 
key that corresponds to the product-identifying information. The method may also 
include transmitting the software key to the user via a text-to-speech server to cause the 
software key to be spoken to the user. Next, the method includes entering the software 
key into the diagnostic device to unlock the at least one feature. 

In another aspect, a meHiod of imlocking at least one feature of a diagnostic 
device is provided. The method may include receiving, from a user, product-identifying 
information (such as a serial number) for the diagnostic device, and identifying a software 
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key flaat corresponds to the product-identifying information. The method may also 
include receiving payment information from the user and transmitting the software key to 
the user via a text-to-speech server to cause the software key to be spoken to the user. 
Next, the method includes entering the software key into the diagnostic device to unlock 

5 the at least one feature. 

In another aspect, a method of imlocking at least one feature of a diagnostic 
device is provided. The method may include receiving, from a user, product-idratifying 
information (such as a serial number) for the diagnostic device, and identifying a software 
key that corresponds to the product-identifying information. The method may also 

10 include receiving from the user information regarding the feature or features the user 
wishes to unlock^ and transmitting the software key for that feature or features to the user 
via a text-to-speech server to cause the software key to be spoken to the user. Next, the 
method includes entering the software key into the diagnostic device to xmlock the at least 
one feature. 

15 

BRIEF DESCRIPTION OF THE DRAWINGS 

Exemplary embodiments of the present system and method are described herein 
with reference to the drawings, in which: 

Figure 1 illustrates a network in which an exemplary raibodiment of the present 
20 system may be implemented; and 

Figure 2 is a flow chart illustrating the operation of an exemplary embodiment of 
the present system. 
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DETAILED DESCRIPTION 

The present method and system allows users of software-based, stand-alone 
equipment to obtain and enter software keys that enable or unlock the equipment's 

5 features without a conventional Ihtemet coimection. If a user registers a stand-alone 
device, such as an automotive tester, with the tester's manufacturer, the serial number for 
the device can be stored in a database maintained by the manufacturer. Corresponding to 
a serial number, one or more software keys can be generated to unlock features or install 
new software. Since the software keys are associated with a particular device (by serial 

1 0 number and features to be enabled), they can only be used to enable or unlock a xmique 
device's features. For example, an automotive tester may have an extensive set of 
features installed even though not all of them are enabled when the tester is first 
purchased. By allowing users to purchase features (or use them on a limited-time free 
trial basis), the tester's manufacturer has flexibiUty in what features are provided to users. 

15 The present system may be used to enable features or update the software of a 

portable, stand-alone automotive diagnostic device. Such a device may be, for example. 
Snap-on' s MODIS system, which is a modular, mggedized diagnostic platfoim that 
replaces multiple pieces of automotive diagnostic equipment. The MODIS system 
utilizes the Windows CE operating system and standard PC-based architecture. The 

20 MODIS system also includes a VGA port to comiect to external monitors, as well as 
infrared, serial and USB ports and a CompactFlash interface. Any of various ports and 
interfaces (except the VGA port) can be used for software updates and other 
communications. For example, software updates may be accomplished by CD-ROM 
inserted in a standard PC that is connected to the MODIS. Software updates may also be 

25 made directly via CompactFlash memory cards. In addition, MODIS may have extensive 
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software features and functionality built-in but inaccessible to users imtil the users pay for 
the features. 

In addition to the MODIS sjirstem, the present method and system is compatible 
with other types of equipment, such as diagnostic equipment implemented in Personal 
5 Digital Assistants (PDAs) and in Snap-on's Automotive Scan Tools such as the MT2500 
Scanner and the MTG2500 Color Graphing Scanner. The method and system is also 
appropriate for use with the Snap-on Vantage Power Graphing Meter, which is a 
component tester that combines a graphing digital multimeter with a diagnostic database 
for testing engine-management components, transmission sensors and components, ABS 
10 systems, and the Hke. Moreover, the present method and system is not limited to 
operation with these noted, exemplary devices, but can instead be employed with a wide 
variety of devices. 

Architecture 

In an exemplary embodiment, a system for unlocking software features is 
15 implemented in a network, as illustrated in Figure 1, User's initial requests can be made 
from telecommunications devices such a telephone 12, that communicate with telephone 
switch 14. Telephone switch 14 is in turn in communication with voice platform 16, 
which serves as an interface to network 18. Network 18 can be, or can include, the 
Internet A manufacturer's or service provider's server, such as server 20, has access to a 
20 manufacturer's enterprise database 22 as well as network 18. Further, the server 20 may 
be protected from unauthorized access by a firewall (not shown). 

Telephone 12 may be either a wireless or landline telephone, or it may be any 
voice-enabled telecommunications device, such as a Voice-Over-IP device. Telephone 
switch 14 may be a conventional PubUc-Switched Telephone Network (PSTN) switch or 
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any other suitable routing or switching device. Voice platform 16 may be, for example, a 
Nuance Voice Platform manufactured by Nuance Communications, Inc., although voice 
platform 16 may be any other suitable voice platform. Voice platform 16 may include a 
"conversation server" that in turn includes a VoiceXML interpreter integrated with 
speech recognition, text-to-speech, and voice authentication software. Voice platfomi 16 
can accept Dual-Tone MultiFrequency (DTMF), pulse-dialed, or speech input from 
telephone 12. 

The functions performed by server 20 could be implemented with one or more 
interconnected, commercially available server-class computers such as the Sun Solaris, 
Dell NT, IBM AIX, or other servers. A server such as server 20 may generally be 
referred to as an enterprise server, and may also include a memory, a processor, and 
instructions stored in the memory that are executable by the pixjcessor to carry out various 
functions, including the functions described here. As mentioned above, server 20 is in 
communication with database 22, which may include a manufacturer's (tiiat is, the 
manufacturer of a diagnostic device to be unlocked) financial, manufactiiring, order 
processing, and product registration information, and may also include software keys 
associated with particular products. Database 22 may be part of an enterprise resource 
planning (ERP) system such as the one developed by BaaN. Other typical ERP systems 
that could be used include the R/3 enterprise plication developed by SAP AG of 
Walldorf, Germany, as well as those developed by PeopleSoft, and Oracle. 
Operation 

An owner or user of a diagnostic device may initially purchase the device with an 
understanding that not all features of the device are enabled, but that some features may 
be purchased or- used on a trial basis at a later time. The user may also realize that 
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diagnostic devices such as flie MODIS system can be updated to improve perfonnance 
and prevent obsolescence. The features can be unlocked by entry of a software key 
associated with the particular device. As a concajete example, suppose a user purchased a 
MODIS system, at which time the product was registered. In the example, assume the 
user chose not to purchase Asian hnport Troubleshooting information that could be 
available to the MODIS system, or that the user chose not to purchase frequency- 
measuring capabiUty (as another example). Product registration could include the part 
number and serial number of the device, as well as the owner's business or financial 
information, or both. 

Now suppose the user is working on the transmission of a Honda automobile. The 
user may take steps to access MODIS' "Asian Import Transmission Fast-Track 
Troubleshooter" to learn about troubleshooting the particular transmission. Since the 
information sought is not enabled, however, the requested information could, for 
example, be "grayed-out," indicating that it is unavailable. Alternatively, the user may 
have purchased MODIS prior to the model year of the transmission for which information 
is sought. In either case, attempting to access unavailable or out-of-date features could 
result, in addition to a grayed-out menu item, in the display of a telephone support 
number or website address the user could use to enable the feature. On-screen display of 
a telephone number is not, however, critical to all embodiments of the present system. 
For example, a telephone support number or web address could be made available in the 
original product literature, over the Internet, or permanently displayed on the tool. 

In addition to displaying a telephone number, the diagnostic device could also 
display a unique feature identifier or device identifier that the user could hansmit in order 
to request a software key. If the information on the device is simply out of date, the user 
might first need to download or install more recent information, which could be made 
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freely available from numerous sources, as discussed above (e.g., Intemet, CD-ROM, 
Flash Memory, and tiie like). 

Figure 2 is a flow chart of various functions that may be carried out in accordance 
with the exenq)lary embodiment to allow the user to imlock the desired information. 
First, the user could use telephone 12 to call a product support telq)hone number, as 
shown in block 30. Voice platform 16, upon receiving a call to the proper product 
support number could req)onsively access a specific directory or website within the 
manufecturer's server 20. The server 20 may transmit XML, VXML, or other code that 
then directs the voice platform to play an appropriate (according to the dialed number) 
prerecorded prompt message (or to perform a text-to-speech conveasion of a prompt 
message) that says, for example: 

"Welcome to the Sn^-on Diagnostics registered products system. Please select 
your product from the following menu: One, scanners; Two, lab scopes; Three, engine 
analyzers; Four, component testers (system pauses for response). Please enter your serial 
number." The user may also be prompted to select a feature or features that he wishes to 
enable, as shown at block 32, or there may be only one non-enabled feature or feature set 
so that selecting a feature is not necessary. The user's input can be eitibier spoken or 
entered via the telephone keypad or other suitable data entry device. Next, as shown at 
block 34, the server 20 receives the serial number for a particular product type (for 
example, category 3 from the user's response to the prompt) and, if applicable, the feature 
to be enabled. As an alternative, any product-identifying information could be entered in 
lieu of a serial number. Once the serial number is verified by access to the database 22, 
the server 20 can either generate a software key for a particular feature or the entire 
product, or, alternatively, can look up a stored software key corresponding to the serial 
nimiber. 
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At block 36, the server 20 can authorize the user. This authorization can comprise 
receiving a credit card number, for example, or verifying that the owner of the device 
identified by the user has a preexisting relationship with the manufacturer so that the user 
can be charged accordingly. Alternatively, the system can respond to software key 
5 requests without user authorization i^ for example, features are to be unlocked for a fiee 
trial period. 

At block 38, the software key is transnntted to the user via network 18 and voice 
platform 16. The software key may be transmitted fiom the server 20 in VXML 
(VoiceXML) format so that the voice platform can perform a text-to-speech conversion, 

1 0 shown at block 40, although other text formats, such as HTTP or XML are also possible. 
The software key may be a simple alphanumeric such as "98 G" although more or fewer 
characters could be used. As an alternative to speech, the software key could be sent to 
users via the Ihtemet, the PSTN, or both, in other formats, such as text-based formats or 
markup languages, which would enable users to view software keys on handheld devices 

15 or telephone text display screens. 

Next, as shown at block 42, the user receives the software key that unlocks the 
applicable features of his particular device. The user can then enter the software key to 
unlock the features of the device. The software key may be entered by a peripheral 
component connected to the diagnostic device, such as a handheld PDA or a personal 

20 computer, or it may be entered directly by a built-in input device. As an example, the 
MODIS unit includes a Thumb Pad and selection keys that, in combination, operate much 
as a computer mouse to allow direct user input. As another alternative, the software key 
could be 'beamed" via infrared Unk, to the MODIS from a PDA or ceUular phone. Other 
key entry methods can also be used. 
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The software or feature to be enabled on the diagnostic device can be enabled by 
entry of the software key. To accompUsh this, the software key may be verified by a user 
key verifier software routine in the diagnostic device. Depending on the level of security 
required or desired, the enabling routine can verify whether the software key entered 
5 matches unique product identifying infomiation, requested feature information, user 
information, date, and the like. For exanaple, the user key verifier routine could perform 
an algorithm on the user key to generate a match with the last six digits of a product serial 
number embedded within a chipset in the diagnostic device. For more security, the 
verifier routine could restrict feature or update enablement to a certain time period after 

1 0 the key is generated. If less security is required, one or more software keys may enable a 
group of devices, rather than just one unique diagnostic device. Because a verifier routine 
can be used, it is not necessary to store valid key data in diagnostic devices at the time of 
manufacture, although doing so would also be possible. Other methods of key 
verification are possible. 

15 The present system allows untrained users to update, upgrade, or enable features 

of stand-alone equipment that may not be (although it could be) connected to the Intemet. 
Further, such modifications can be made using, for example, an ordinary telephone, a 
cellular telephone, a PDA, or the like. Because an enterprise server and a voice platform 
as described can woric in combmation to provide a seamless user experience by 

20 dynamically accommodating interactions with a database, Uttle or no human intervention 
is required to operate the system. In addition, the system can service customer requests 
around the clock at minimal incremental cost for each transaction. The system is also 
scalable, in that virtually any service that could be implemented through authorized, 
automated access to a manufacturer's database, can easily be provided via telephone. 
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Although several possible embodiments of an apparatus, system, and method has 
been described, various changes and modifications may be made or suggested by those 
skilled in the art without departing from the scope of the claims that follow. 
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